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1. TITLE 

5 

RTCP Reporting for Multi-User Services in Wireless Networks 
Technical £ield o£ tbe invention 

10 

Olie present invention relates to a method for performing 
multicast in a telecommunication network. 

Especially is the present application applicable in a point- 
15 to-point packet-switched telecommunication network. 

2. BACKGROUND 

Universal Mobile Telecommunication System UMTS is being 
20 developed to offer wireless widebamd multimedia service using 
Internet protocol. The UMTS as a third-generation 3G mobile 
coxnmunication combines streaming with a range of unique 
services, like for example geographical positioning, to 
provide high-quality Internet content to the users. Images, 
25 voice, audio and video content are example of mobile 

multimedia services, which are delivered to the users via 
media streaming and download techniques - It means once the 
content has been put onto a media server, it can be delivered 
on-demand via download or streaming. To download content, the 
30 user clicks on a link and waits for the content to be 

downloaded and playback to begin. Download capabilities are 
easy to integrate since the hypertext transfer protocol 
(HTTP) can be used for downloading files. To apcess streaming 
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data, the user clicks on a link to start playback, which is 
almost immediate. Because streaming is a semi-real time 
service that receives and plays back data at the same time, 
it puts greater demands on protocols and service 
5 implementation, especially when the service is to work over 
networks with little or no quality of service, like this is 
the case in UMTS. The radio resource, which are used on the 
last part of a transmission is to be used in a better way. 



10 



2.1 MULTIMEDIA BROADCAST/MULTICAST SERVICE (MBMS) 



MBMS is a 3GPP release 6 work item, which introduces 
broadcasting euid multicasting into WCDMA and GSM wireless 
networks. Both broadcast and multicast provide transport 
15 efficiency and reduce the load on the content servers (e.g, 
streaming servers) . 

The following figure shows the current MBMS architecture, 
introducing a new network entity, called the Multicast 
Broadcast Service Center (MB-SC) . 



ERICSSON ^ 
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The current intention is to standardize a ^simple' broadcast 
solution in the radio network. Such a solution implies that 
there is only a downlink channel for data traffic (i.e. a 
common/ shared downlink channel) but no uplink channel. Thus, 
no RTCP reports can be sent from the UEs (group members). 
Note that this radio network solution is not fully settled 
and that additional RTCP reports or limited RTCP reports (see 
below for more details) may still apply. 

2.2 PAClCfiT SWITCHED STREASSXN6 SERVXCK (PSS) 

PSS specifies the 3GPP architecture, network entities and 
protocols for streaming services in wireless networks tl] / 
[2] . The 3GPP PSS architecttire is reflected below. 

ERICSSON ^ 

3GPP streaming Architecture 



streaming 
I OHpnt 




The following figure shows the streaming protocols [21 . RTP 
is used to transport the dynamic payload, such as video, 
audio and data. 
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2.3 RE2^-TIME TKANSPORT (CONTROI>) PROTOCOZt 

(RTP/RTCP) 

5 • The Real-time Transport Protocol (RTP) provides end-to-end 
network transport fxmctions suitable for applications 
transmitting real-time data, sucli as audio, video or 
simulation data, over multficast or \anicast network seirvices. 
The functions provided by RTP include payload type 

10 identification, sequence numbering, timestamping, and 

delivery monitoring. RTP is also discussed in the Audio /Video 
Transport working group in IETF, as the protocol for real- 
time transmission of audio and video over UDP and IP 
multicast. 

15 

The data transport is augmented by a control protocol (RTCP) , 
which is used to monitor the QoS and to convey information 
about the participants in an ongoing session. Each media 
stream in a conference is transmitted as a separate RTP 
20 session (with a separate RTCP stream) . RTCP reports provide 
statistics about the data received from a particular source. 
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such as the number of packets lost since the previous report,, 
the cumulative nxxmber of packets lost, the interarrival 
jitter, etc. An additional draft defines a format for 
extensions to the RTCP sender and receiver reports. 

5 

RTP Control Protocol - RTCP (Introduction to Chapter 6 of 
RFC1889) 

The RTP control -protocol (RTCP) is based on the periodic 
10 transmission of control packets to all participants in the 
session, using the same distribution mechanism as the data 
packets. The underlying protocol must provide multiplexing of 
the data and control packets, for example using separate port 
numbers with UDP. RTCP performs four functions: 

15 

1. The primary function is to provide feedback on the 
quality of the data distribution. This is an integral part of 
the RTP's role as a transport protocol and is related to the 
flow and congestion control functions of other transport 

20 protocols. The feedback may be directly useful for control of 
adaptive encodings [8,9], but experiments with XP 
multicasting have shown that it is also critical to get 
feedback from the receivers to diagnose faults in the 
distribution. Sending reception feedback reports to all 

25 participants allows one who is observing problems to evaluate 
whether those problems are local or global. With a 
distribution mechanism like IP multicast, it is also possible 
for an entity such as a network service provider who is not 
otherwise involved in the session to receive the feedback 

30 information and act as a third-party monitor to diagnose 

network problems. This feedback function is performed by the 
RTCP sender and receiver reports, described below in Section 
6.3. 

35 2. RTCP carries a persistent transport- level identifier for 
an RTP source called the canonical name or CNAHE, Section . 
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6.4.1. Since the SSRC identifier may change if a conflict. is . , . 
discovered or a progrsun is restarted, receivers require the 
CNAME to keep track of each participant. Receivers also 
require the CNAME to associate multiple data streams from a 
5 given participant in a set of related RTP sessions, for 
example to synchronize audio and video. 

3 . The first two f \mctions require that all participants 
send RTCP packets, therefore the rate must be controlled in 

10 order for RTP to scale up to a large nxamber of participants . 
By having each participant send its control packets to all 
the others, each can independently observe the nvunber of 
participants. This number is used to calculate the rate at 
which the packets are sent, as explained in Section 6.2. 

15 

4. A fourth, optional function is to convey minimal session 
control information, for example participant identification 
to be displayed in the user interface. This is most likely to 
be useful' in "loosely controlled*' sessions where participants 

20 enter and leave without membership control or parameter 

negotiation. RTCP serves as a convenient channel to reach all 
the participants, but it is not necessairily expected to. 
support all the control communication requirements of axi 
application. A higher- level session control protocol, which 

25 is beyond the scope of this document, may be needed. 

Functions 1-3 are mandatory when RTP is used in the IP 
multicast environment, and are recommended for all 
environments. RTP application designers are advised to avoid 
30 mechanisms that can only work in unicast mode and will not 
scale to larger numbers. 

RTCP Transmission Interval (Chapter 6.2 of RFC1889) 
[...] 

35 
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For each session, it- is assumed that the data traffic is 
siibject to an aggregate limit called the "session bandwidth" 
to be divided among the participants. This baoidwidth might be 
reserved and the limit enforced by the network, or .it might 
5 just be a reasonable share. The session bandwidth may be 
chosen based or some cost or a priori knowledge of the 
available network bandwidth for the session. It is somewhat 
independent of the media encoding, but the encoding choice 
may be limited by the session bandwidth. The session 

10 bandwidth parameter is expected to be supplied by a session 
management application when it invokes a media application, 
but media applications may also set a default based on the 
single-sender data bandwidth for the encoding selected for 
the session. The application may also enforce bandwidth 

15 limits based on multicast scope rules or other criteria. 
[...1 

The control traffic should be limited to a small and known 
fraction of the session bcindwidth: small so that the primary 
fxinction of the transport protocol to carry data is not 

20 impaired; known so that the control traffic can be included 
in the bandwidth specification given to a resource 
reservation protocol, and so that each participant can 
independently calculate its share. It is suggested that the 
fraction of the session bandwidth allocated to RTCP be fixed 

25 at 5%. While the value of this and other constants in the 

interval calculation is not critical, all participants in the 
session must use the same values so the same interval will be 
calculated. Therefore, these constants should be fixed for a 
particular profile. 

30 [...] 

Maintaining the n\unber of session members 

Calculation of the RTCP packet interval depends upon an 
35 estimate of the number of sites participating in the session. 
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New sites are added to the count .when they are heard, and an 
entry for each is created in a table indexed by the SSRC or 
CSRC identifier (see Section 8.2 of rfcl889) to keep track of 
them. New entries may not be considered valid until multiple 
5 packets carrying the new SSRC have been received (see 

Appendix A.l of rfcl889) . Entries may be deleted from the 
table when an RTCP BYE packet with the corresponding SSRC 
identifier is received. 

10 Both RTP and RTCP have been engineered" for multicast. 
Definitions from [RFC18891 

Mixer: An intermediate system that receives RTP packets from 
15 one or more sources, possibly changes the data format, 

combines the packets in some manner and then forwards a new 
RTP packet. Since the timing among multiple input sources 
will not generally be synchronized, the mixer will make 
timing adjustments among the streams and generate its own 
20 timing for the combined stream. Thus, all data packets 
- originating from a mixer will be identified as having the 
mixer as their synchronization source. 

Translator: An intermediate system that forwards RTP packets • 
with their synchronization source identifier intact. Examples 
25 of translators include devices that convert encodings without 
mixing, replicators from multicast to unicast, and 
application- level filters in firewalls. 

Currently a new, revised version of the RTP/RTCP 
30 specification is under preparation in the IETF working group 
mmusic (51 . Main change compared to the current version (only: 
those, which are relevant for this invention) is, that RTCP 
receiver reporting can be suppressed. RTCP sender reporting 
is still mandatory. It is necessary because of inter -media 
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synchronization (e.g. lip- synchronization when audio and 
video are transmitted separately) and for sender 
identification. Suppressing of RTCP packet is necessary for 
Unidirectional Link Support like in case of digital Broadcast 
systems . 

More specific details about processing of RTCP packets in 
Translators and Mixers is in [RFC1889] chapter 7. 
Problem of the Existing Technology 

3- PROBLEM OF THE EXISTING TECHNOLOGY 

RTP/RTCP was mainly designed to enable IP based video and 
audio conferencing services. All participants connected via 
fixed, bi-directional connections. In conferencing scenarios, 
all members would like to know, who is actually part of the 
groups. In particular senders would like to know, who is 
listening. Anonymous groups with one sender and several 
thousands of receivers were not really in the scope. 

In mobile scenarios usually one- to-many data distribution 
scenarios are of major interest. One sender in the fixed part 
on the network sends information to a very large group of 
users. The group size varies between several thousands and 
millions of mobile receivers. According to the RTCP 
specification, each member of the group knows the entire* set 
group members (all other receivers), who also just would like 
to receive the information. Knowing all group members is 
important for session control but also to calculate the RTCP 
report rate. Knowing all other participants of a multicast 
session is important for conferencing scenarios, but uuiwanted 
in one- to-many information distribution scenarios. It is very 
likely, that receivers would like to stay anonymous. In case 
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the receiver pays for incoming trSiffic volume, receiver . 
information is even more unwanted. 

The RTCP transmission interval to send reports to the sender 
5 and also to other receivers is derived from the group size of 
the session- The RTCP transmission interval shall be 
increased with increasing size of the multicast group, i.e. 
with increasing number of receivers. The dependency prevents 
the sender from being bombed by too many RTCP messages. With 
• 10- • a fixed RTCP transmission rate, the number of RTGP-packets in 
the system would increase linearly with increasing n\amber of 
group members and overload each sender. Therefore, each 
participant needs to receive RTCP packets form neighboring 
participants . 



IS 



20 



The one-to-many data distribution scenario is also depicted 
in the following figure. Note. Receiver 2 and Receiver 3 send 
their RTCP packet (RR for RTCP Receiver Report) like Receiver 
1 to the entire group. AH reports from receivers (according 
to rfc 1889 "Receiver Reports") contain in this scenario one 
reception report block, since only one sender is active. The 
sender on the other side sends so-called "sender reports" . In 
this scenario, the sender report contains zero reception 
report block. This sender is the only sender. 



25 
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5 In case of radio networks with scarce resources and dense 
client populations {i.e. many group members in the same 
geographical area such as a cell), the multicast reporting 
will waste air interface resources and potentially overloads 
the network servers (in case of suppressing RTCP packets to 

10 the entire group to save radio resources) . *At the beginning 

of a multicast session there is also a risk of temporary RTCP 
overload. Since the group members need reports from other 
users to adjust their reporting intervals, it may take some 
time before this saturates in a system with relatively high 

15 latency links (compared to fixed networks). This depends also 
on the initial value for RTCP reporting interval... 

Furthermore, in the multicast solution as preferred by 
Ericsson (and others) there will only be a downlink and no 

20 uplink channel . This ixnplies that the members cannot send 
RTCP reports to the source. It is anyhow questionable what 
the source should do if an RTCP report from a single client 
indicates that several RTP frames were corrupted or lost and 
that client would better be served with a lower data rate. 

25 This is especially a big question mark in wireless networks 

with increasingly heterogeneous clients. In current multicast 
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solutions the... sour c.e will.^?ither ignore such reports .or adapt 
to the ^slowest' receiver. Both are not adequate when clients 
are charged for the service and the bearer that is used for 
the service (as in WCDMA and GSM networks) . 

So. basically there are the following problems regarding the 
RTCP reporting in multicast sessions in wireless networks: 

• Providing efficient quality feedback to the sender 

• Sending receiver information (Name etc) only to 
the sender instead of the entire group. As soon as the 
other receiver don't get group size information, the 
RTCP transmission interval is calculated wrong 

• Inefficient use of scarce radio resources (but 
also backbone resources) 

• Risk of server (RNC, SGSN, GGSN, etc.) overload 
(e.g. 10000 members in a football arena) 

• Source must adapt to slowest client (problem in 
case of heterogeneous networks) 

• Long delay before the source is aware of problems 
(like for the single-user service case) 

• RTCP reports contain only info relevant for single 
client. This implies that the source needs to perform a 
lot of reporting analyses in case of large user 
sessions. This is especially a waste if the members can 
be grouped into one or a few access networks with very 
similar characteristics and behavior 

• RTCP reports don't contain all necessary 
information for wireless networks 

4. SOLUTION 

4.1 BASIC IDEA 
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This invention is- mainly about how to generate RTCP receiver 
reports (from scratch) on an intermediate node based on 
information from the radio network and/or the client. The 
intermediate node can either be an RNC or a node at the Gi 
interface, which receives information from the RNC, 

RTCP receiver reports are either generates only based on 
information from the RNC or based on additional information 
from the client application. 

RTCP can be used in a modified way between the client 
application and the intermediate node to relay information 
additional information. RTCP messages are sent on event- 
basis. The additional information from the client 
application, which are received at the intermediate node, can 
impact the radio resource management (e.g. increase FACH 
power) 

By changing the standard RTCP handling in multicast cases, in 
the way of this invention, anonymity between users is 
archived. 

The invention overcomes the problems as listed in chapter 3 
by having the first server or any intermediate node in the 
wireless network taking care of an * aggregated' RTCP. 
reporting, rather than that each individual takes care of its 
own reports. RTCP receiver reports contain important feedback 
about reception conditions from the client. RTCP receiver 
reports are additionally important for congestion control 
mechanisms. Therefore, the sender of the RTP multicast stream 
shall still receive RTCP receiver reports. 

The basic idea is to have an intermediate node in the 
wireless network taking care of an 'aggregated' RTCP 
reporting, rather than that each user individual performs its 
own reports. The aggregated' RTCP reporting or general one 
feedback report per multicast group is generated. A real time 

P17101-MAZ 23 October, 2002 
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defcermination of distribution characteristics^ is- performed 
considering cell related characteristics determination and 
the group structtire and. The generation of the feedback 
report is based on the real time determination of 

5 distribution characteristics wherein said feedback report 

includes additional information including the number of users 
to which said feedback report applies. Said feedback report 
is sent to the multicast source, which utilizes the group 
feedback report by considering the percentage of the users 

10 for which said feedback report applies. The 

multicast /broadcast transmission is adapted accordingly to 
the utilized feedback report, 

SxHranaxy : 

15 The present invention provides mechanism for efficient and 
intelligent service feedback generation (e.g. RTCP receiver 
reports), reporting and utilization for multicast and 
broadcast sessions, which conveys the following: 

20 1. Determination of group structures. E.g. a low speed and a 
high speed, multicast group, (optional) 

2 .Negotiation of « feedback reporting mechanism'' between the 
network and the clients, (optional) 

3. Real--time determination of distribution characteristics 
25 •Cell related characteristics determination 

• On the level of a geographical area (one or several radio 
cells) and 

• applicable to a group of clients (e.g. all clients in the 
same cell, all clients in the same group of cells AND with 

30 similar conditions, such as same UE type, same service QoS, 
same time of registration) 

4. Generation of one feedback report per group (at least not 
one per client), with additional info, such as: 

• The nxxtnber of clients to which the report applies 
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•Group -related adaptation proposal, considering the 
characteristics of the access network (e.g. WCDMA, WLAN) . 
E.g. only propose multiple unicast if that's possible, 
propose handover overlay cell or other access network, etc. 
This statement means to have the RTCP generating node (e.g. . 
RNOmake a proposal to the source on how to adapt the stream 
for the corresponding group of users. The reason for this is 
that the RNC may have information (e.g. radio characteristics 
of the cell area) that the source does not have and it may 
thus be in a better situation to judge how the stream 
could/ should be adapted. As an example, RTCP currently 
indicates that the reception quality is not good, which 
triggers a source to go down with the bitrate (to the next 
lower level) . An RNC that determines an almost overloaded 
cell (and many session initiations per time unit) could 
indicate that the bitrate has to be decreased by 50%, rather 
than going to the next lower lower (e.g. 80% of the current 
bitrate) - 

5. Utilization of the group feedback report by the source (or. 
a proxy) , considering the percentage of clients for which the 
feedback applies, to 

•Announce a new '^channel* to the clients (e.g. unicast or 
other access network) 

• Adapt the stream (e.g. reduce bit-rate, switch to more 
reliable codec) 

Furthermore, optionally the RTCP report could contain (in 
addition to the number of users) the actual end-user 
addresses, since this may be of interest to the other users 
and/or the source. 

The following picture summarizes the three main options of 
the invention: 
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1. No RTCP reporting over the air interface and 
generation of RTCP messages frcan scratch in an 
Intermediate node. Reports are generated on the basis of 
the received RTF stream and potentially on RRM knowledge 
about a certain cell or area. 

2. In certain exceptional situations the UE is 
allowed to send RTCP reports on unicast uplink channels. 
These are then used as additional input to form an 
aggregated RTCP message as in alternative 1. 

3 . Another optioii of the invention is to refrain from 
sending RTCP reports to all multicast receivers in order 
to maintain anonymity between the users. In addition 
this reduces the dovmlink load in the network. 
Typically, users are also not interested in who is 
receiving the information, as well. Thus, RTCP reports 
except the Sender Reports are not sent in downlink 
direction. 
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The RNC compiles a single RTCP report from the information 
that is available from the lower layer protocols and 
mechanisms and pretends to be a single client. Note that the 
existing RTCP reporting as defined in [1] may be enhanced to 
reflect aggregated RTCP reports. 

The basic idea is reflected in the following figure* 



Existing Tecrhnology 




channel 



Invention 



Aggregated & optimized 
RTCP reporting 



No or limited 
KTCP reporting 




RNC 



shared 
channel 



For the reporting from the clients itself, this invention 
discusses 4 alternatives, each optimized for a different 
multicast service scenario. 

1. The client refrains from sending RTCP reports on 
RTP/RTCP level. This is currently discussed as a 
proposal for the standards. This is obviously not new 
nor inventive* 

2. All RTCP reports are blocked in the UE (no impacts 
on RTCP level) 

P17101-MAZ 23 October, 2002 



BEST AVAILABLE COPY 




18 

3 . For 1 and 2 -there- is an option to send only RTCP 
reports with special information. I.e. no regular RTCP 
reports are sent. Only in case of extraordinary events, 
the RTCP reporting is done- In 1. this is handled on 

5 . RTCP level, whereas in 2. the UE would have to filter 

the regular RTCP reports. Which RTCP reports are 
regarded as extraordinary is service and access network 
dependent and may be subject for negotiation between the 
source and the destinations and/or between the access 

10 ' networks and the destinations. 

4. To refrain the clients from sending RTCP Receiver 
Reports and generate RTCP. receiver reports in an 
intermediate, enhanced node. This node basically acts 
like a mixer and hides the receivers of an entire cell. 

15 The extended mixer gets information from the RNC and 

creates a RTCP report from this. Additionally, RTCP 
packets with special wireless information can be used 
and filtered out at the RTCP generation node (see 3) . 



20 The following figure depicts an alternative, logical 

architecture. The functionality of getting the necessary 
quality information at cell level is physically split from 
the node, which is compiling and sending the RTCP reports. 
No RTCP receiver reports (sender reports are still mandatory) 

25 are sent from the mobile client. Special node (or function in 
e.g. GGSN; MRF, etc) outside the mobile core generates the 
RTCP receiver reports. RTCP receiver reports are sent as per- 
RNC or per-cell aggregate. This allows the sender to collect 
and evaluate the quality feedback (maybe adapt (sub- 

30 ) streams), but is omits any session participations 
information to other mobile clients. 
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By providing per-cell or per-RNC RTCP reports also increases 
the periodicity of quality feedback infoonnation and allows a 
sender to adapt faster to changing conditions. The RTCP 
reporting interval depends on the number of participants in 
the session. 



There exist different detailed solutions for different 
scenarios . 

4J2.1 Broadcast Scenario 

The broadcast scenario is chsuracterized by a radio access 
set-up where no up-link is present- This means that the 
multicast datagrams are sent in downlink direction, but no 
client response is sent back. 

In the current MBMS discussion this is seen as the first step 
to support multicast in WCDMA. 



4.2 



TECHNICAL DESCRIPTION 
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The lack of a -return channel prohibits that RTCP feedback is- 
sent back frran the clients. Even though - depending on how 
protocols stacks are built - RTCP messages might be generated 
there exist no medium to deliver these. 

However, for the current RTP RFC (RFC1889). the used of RTCP 
receiver reports is mandatory in multicast sessions. In 
particular it is important that these are received by the 
multicast sender to signal that clients are still listing. 
The current revision of the RTP rfc (draf t-ietf -avt-rtp-new- 
ll.txt) [6] provides a feature to suppress RTCP receiver 
report usage. However, by omitting RTCP receiver reports also 
an intportant means of getting quality feedback from the 
receivers is omitted. The source cannot adapt to changing 
conditions and also cannot provide alternative streams. 

(Inventive) For the broadcast scenario the idea is that RTCP 
messages are generated in a network node, preferably the RNC 
for WCDMA (BSC for GPRS?) - This is basically the logical 
location for generating the RTCP reports. The new RTCP 
receiver report is created based on radio related 
information. Therefore, the function of creating and sending 
an RTCP receiver report and the data collection function can 
be split. 

Different RTCP reports do exist. In particular these are 

Sender r^ort (SR) 

Receiver report (RR) 

Source Description Items (SDES) 

Bye-Message (BYE) 

Application specific functions (APP) 

Messages can be bundled to form a so-called compound message. 
Each compound message must contain a SDES RTCP message. 



P17101-MAZ 



23 October, 



21 



For tlie invention in particular the Receiver report (RR) is 
important. This is the message which needs to be received by 
the sender in order to adapt to changing bandwidth 
conditions . 

We propose that such receiver reports are generated in e.g. 
the RNC based on the knowledge the RNC has about the link 
condition in one or more cells- The RNC could generate on 
message for each cell it is responsible for or even form a 
single message for all cells. 

The RR messages include the following fields[l]: • 

SSRC_n (source identifier) : 32 bits 

The SSRC identifier of the source to which the information 

in 

this reception report block pertains. 

fraction lost: 8 bits 

The fraction of RTP data packets from soixrce SSRCji lost 

since 

the previous SR or RR packet was sent, eaqpressed as a fixed 
point number. 

c\imulative number of packets lost: 24 bits 

The total number of RTP data packets from source SSRC n 
that " 

have been lost since the beginning of reception. 

extended highest sequence number received: 32 bits 

The low 16 bits contain the highest sequence number 
received in 

an RTP data packet from source SSRC_n, and the most 
significant 

16 bits extend that sequence nxanber with the corresponding 

count 

of seq[uence number cycles. 

interarrival jitter: 32 bits 

An estimate of the statistical variance of the RTP data 

packet 

interarrival time, measured in times tamp units and 
expressed as 

an unsigned integer. The interarrival jitter j is defined 

to be 

the mean deviation (smoothed absolute value) of the 
difference D 

in packet spacing at the receiver con^ared to the sender 

for a 

pair of packets. 
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last SR timestamp (LSR) : 32 bits 

The middle 32 bits out of 64 in the NTP times tamp (as 

explained^ Section 4) received as part of the most recent RTCP 

sender ^.^^^^ ^^^^ packet from source SSRC_n. If no SR has been 
received yet, the field is set to zero. 

delay since last SR (DLSR) : 32 bits ^ ^ ^ 

The delay, expressed in units of 1/65536 seconds, between 
receiving the last SR packet from source SSRC_n and sendxng 

' reception report block. If no SR packet has been received 

yet 

from SSRC_n, the DLSR field is set to zero. 



The values for the entries in the RR need to be generated. 
The first one is sinqply the sender ID, which is known. 

(Inventive) For the second one, the fraction of lost packets, 
there are different alternatives. An appropriate value could 
be either the loss fraction seen by the RNC, or an estimate 
by the RNC depending on the current cell situation (e.g. 
radio resource usage, interference, ...) and on the reliability 
level chosen for the transmission in the cell. 
Third, the cumulative number of packet losses needs to be 
chosen according to the concept used for the previous one to 
avoid a mismatch. For example, if the loss fraction is based 
on the packet losses seen by the RNC, they should be used for 
this entry as well . 

The highest sequence number received should be the highest 
one the RNC has seen. 

The interarrival jitter could be either based on the jitter 
observed by the PNC, or probably better by an estimated value 
taking the link parameters into account (e.g. whether ARQ or 
repetition coding or FEC are used to ensure a certain degree 
of reliability) . 
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4.2.2 Multicast Scenario 

The multicast scenario differs from the broadcast scenario 
mainly in that a return channel is available. This as such 
would make end-to-end RTCP signaling possible, but because of 
problems indicated in chapter 0, it is here proposed to 
generate the RTCP messages at a network node, preferably the 
RNC for WCDMA (BSC for GPRS?). There are then two 
possibilities with the current version of RFC1889: 

1. The UE generated RTCP messages are discarded in the UE and 
generated *^from scratch" in the RNC (logically) or an. 
intezrmediate node. With the new revision of RFC1889, the 
source can indicate to the clients, that no RTCP receiver 
reporting shall be used. 

2. The UE generated RTCP messages are transmitted over the 
radio interface to the RNC (logically) , but modified in the 
RNC according to certain principles described below. The RTCP 
message interval for RTCP messages from the UE can be larger 
than the RTCP message interval for RTCP messages from the 
intermediate node to the sender. The UE may even send RTCP • 
messages only event driven, e.g. when certain values a out of 
range. 

The input for setting the different fields of the RR messages 
are the same as for the broadcast scenario. To overcome the 
problems described in chapter 0, the following principles can 
be followed when setting the fields in the RR messages: 

• When using a common transport channel in WCDMA (which is 
at the moment the assun^tion for both multicast and 
broadcast) , there will always be some receivers with 
poor channel conditions suffering from large packet 
loss, while others get good cjuality. The RNC could in 
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•this case 'shield' the poor receiver reports to maintain 
quality for the good users. 
• If PNC detects an overload in a cell and wants to reduce 
the bit rate on the common channel used for JSms. it can 
use the RTCP reports to signal this to the Multicast 
server. This can be either by increasing the measured 
packet loss ratio in the reports, or just reducing the 
highest sequence number received. This will be quicker 
than end-to-end signaling because of the radio interface 
latency and since per user RTCP reporting becomes rare 
for large user groups, as described in chapter 2.3. 

4^3 General Handlii^ 

4.2.3.1 Logical Unit for RTCP Reports Generation 

In the above description the RTCP report generation is done 
in . the BUG. In general, this report generation and all 
related functionality is a logical function that could also 
reside in other network entities, such as e.g. the MB-SC. 
Dedicated protocols could be used to forward the relevant 
information from the RNC to the MB-SC in that case. 

42.3.2 Achieve User Anonymity 

Different from some Multicast applications in the fixed 
Internet like audio and video-conferences, mobile users form 
typically an anonymous community. Users in mobile networks 
which look at the same video clip are most likely not 
interested in knowing the names of other viewers and might 
also not be interested in revealing their identity. 

RTCP messages (RR and SDES messages) according to the 
standard should (which is a clear recommendation to do so) 
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include the identity of users in e.g. the format of his/her 
email-address . 

As discussed above « this is not desirable for the wireless 
multicast scenario, where users would like to maintain their 
5 anonymity and where they also do not wcuit to pay for received 
information they are not interested in ( irreleveucit 
information) . 

Thus, the invention includes to transiait the KTCP messages, 
which are generated either in UEs or the intermediate node, 
10 only back to the RTP stream sender. 

4.2,3.3 Number of Destinations Covered by Aggregated RTCP Report 

Together with the generation of an aggregated RTCP report, 
15 the nuitODer of destinations for which the RTCP report applies 
should optionally be added to the report. This information is 
then potentially considered by the source in case of 
multicast stream adaptations. E.g. if an aggregated RTCP 
report covers thousands of destinations, the source could 
20 adapt for these destinations. If it covers only 10 

destinations in a session where thousands of destinations^ are 
involved (e.g. in other cells), it may be better to advise 
the clients to switch to a unicast session instead. 



25 4.2.4 RTCP handUng in the Intermediate Node 

Each compound RTCP packet must include a Report packet (SR or 
RR) and an SDES CNAME packet. To distinguish between several 
multicast sources, each receiver report (RR) packet is 

30 addressed by the SSRC of the source. Therefore, the 

Intermediate node must process and forward the downstream- 
multicast traffic (from the source to the receivers) £ind 
extract the SSRC of the Multicast Source. The SSRC is 
necessary to address the upstream RTCP receiver report 

35 packets, which are generated in the intermediate node. The 
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number of mobile terminals per cell (plus reception 
conditions per terminal) is provided by the RNC. 

The Intermediate Node must allocate an SSRC identifier for 
5 each mobile terminal. The intermediate node must allocate the 
SSRC on behalf of each mobile terminal like described in 
[RFC18891 chapter 8. Beside the SSRC, the intermediate node 
must also provide a SDES CNAME item for each MT. There are 
several options of choosing the CNAME for a particular user: 
10 • in case of anonymous participation (Source shall not get' 

a clear CNAfilB) , the SDES CNAME item is randomly chosen. 

Is can be in form of <random-number>@host , similar to 

the form described in 6.5.1 of [RFC1889] . The CNAME must 

be unique. 

15 ••In case of a non-anonymous (^TAME, either the operator 

predetermines the user name (e.g. phonenumber@domain) or 
the user specifies the CNAME in a px^eference database. 
Therefore, the intermediate node must maintain a list of MTs 
per cell plus the associated SSRCs (allocated by the 
20 intermediate node) and CNAMEs. The intermediate node 

functionality is possibly included in the BM-SC br the GGSN. 
The content of each RTCP packet is created like described in 
the previous chapters. 
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Figure 2: RTCP receiver report per IVIobile Terminal 

In case the very large user group, which is spread over a 
very large number of cells, the Intermediate node shall send 
5 RTCP packets not per MT but per cell. It is very likely, that 
each cell servers an approximately equal niunber o£ group 
members . 

In this case, the Intermediate node allocates valid SSRCs and 
CNAME £or each cell, which contains group members. The niunber 
10 of send RTCP packets is decreased. The transmission interval 
of RTCP packets and therefore also the reaction time of the 
multicast sovurce decreases by sending per-*cell RTCP packets. 

As an additional RTCP packet type can be introduced into to 
15 weight the RTCP receiver report to the number of users in the 
cell. This RTCP packet type must part of a RTCP comporuid 
packet whenever this RTCP packets contains receiver reports 
. for more than one member. 




Figure 3: RTCP receiver report per cell 



5. BENEFITS OF THE INVENTION 
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This inyention solves, al^l the . pr.Qblems as mentioned in 
chapter 3- In particular, the invention has the following 
benefits: 

o Aggregated RTCP reports, i.e. one RTCP report for 
5 all clients served in the same cell or all clients 

served by the same HNC. 

• The RTCP reports optionally 
contain counters with the number of clients that are 
aggregated in the reports 

10 - • This is the only way of 

reporting in case no uplink channel is available, as in 
the simple broadcast solution that Ericsson is targeting 
in 3GPP R6. 

• This will reduce the load on 

15 the air- interface and in the backbone network. However, 

it will very much reduce the load and the complexity in 
the source (e.g. h\xndreds or thousands of users in the 
same cell) 

• The aggregated RTCP report can 
20 consider all information in the cell, rather than a 

single dedicated RTCP report per client. E.g. in case o"f 
^almost' overload situations, the RNC knows this (before 
congestion is encountered by loosing frames) and can 
report this to the source for all clients in the same 
25 cell." This would improve the quality experience for the 

end-user. 

• In general the reporting is 
faster since the air-interface delay is skipped. This is 
very much the same as for the single-user streaming 

30 case. 

• Due to that the reports are 
aggregated and apply to multiple clients (often even all 
clients, e.g. in case of geographical area related 
multicast sessions) the source now has a means to adapt 
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to the clients, which was not the. case without the 
aggregation. 

o Wireless and multicast specific RTCP reporting 

• Wireless and multicast specific 
5 RTCP reports (info to be added to the IETF RFCs and 

drafts) will take the specifics of wireless networks 
into accoimt and will iinprove the overall service 
quality, 

• Other information from lower 
layer protocols as already known in the RNC, can be 
considered in the reports to further optimize the 
service quality. However, it is just one part of the 
invention to forward additional radio related info to 
the source. Another one is that the RNC considers the 

15. info (because that's where it has the knowledge) and 

. makes an adaptation proposal (see above) to the source . 
With this the source doesn't need to have info about the 
radio network, since it's the radio network that 
converts this info to a known adaptation proposal for 

20 the source. 



6.TERMINOLOGY AND ABBREVIATIONS 

DBTF Internet Engineering Task Force 
25 MBMS Multimedia Broadcast/Multicast Service 

MB-SC Multicast Broadcast Service Center 

QoS Quality of Service 

RTCP Real-time Transport Control Protocol 

RTP Real-time Transport Protocol 
30 UDP User Datagram Protocol 

UE User Equipment 

WG Working Group 
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Claims 

1. Method for reporting on multicast/broadcast transmission 
in network wherein a multicast source provides the 
multicast /broadcast transmission to users being registered 
to multicast groups 



characterised in that 

10 

- group structures of the multicast groups are determined 
and, 

- real time determination of distribution characteristics 
is performed considering cell related characteristics 

15 determination and the group structure and, 

- one feedback report per multicast group based on the 
real time determination of distribution .characteristics is 
generated wherein said feedback report includes additional 
infonaation including the nixrober of users to which said 

20 feedback report applies and group-related adaptation 

proposal, considering the characteristics of the access, 
network and, . 

- the multicast source utilizes the group feedback report 
by considering the percentage of the users for which said 

25 feedback report applies and, 

- the multicast/broadcast transmission is adapted 
accordingly to the utilized feedback report. 



30 



2 . Method according to claim 1 characterised in that the 
determination of the group structures considers speed of 
the multicast /broadcast transmission. 

3. Method according to claim 1 characterised in that a 

negotiation on the applied feedback reporting mechanism 
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. between tlie network and,, the. users, is per formed . at . the 
beginning of a session . 

4. Method according to claim 1 characterised in that the 
group- related adaptation proposal, considering the 
characteristics of. the access network proposes multiple 
unicast if that's possible handover overlay cell or other 
access . 
network 



5. Method according to one of the previous claim characterised 

in that the real-time determination of the distribution 
characteristics is performed on the level of a 
geographical area having one or several radio cells and is 
15 applicable to the group of users. 

6. Method according to one of the previous claim characterised 

in that the group structure of the users includes all 
users in the same cell or all users in the same group of 
cells and with similar conditions "like for exait«>le same 
client terminal type, same Quality of Service, same time 
of registration. 



7, Method according to one of the previous claim characterised 
' in that the additional information of the feedback report 

includes group-related adaptation proposal, considering 
the characteristics of the access network. 

8. Method according to one of the previous claim characterised 

in that the adaptation of the multicast /broadcast 
transmission includes the announcement of a new 
transmission channel to the users or reducing of the bit- 
rate or switching to more reliable codecs. 
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9 . Intermediate node adapted to perform reporting on 
multicast /broadcast transmission wherein a multicast 
source provides the multicast/broadcast transmission to 
users being registered to multicast groups 

characterised hy 

-means for providing real time determination of 
distribution characteristics considering cell related 
characteristics determination and the group structure 
and, 

-means for generation of feedback report per multicast 
group wherein said feedback report includes additional 
information including the number of users to which 
said feedback report applies and 

-means for sending the feedback report to the multicast 
source 

10. Multicast source adapted to jperform reporting on 
multicast/broadcast transmission wherein a multicast 
source provides the multicast/broadcast transmission, to 
users being registered to multicast groups 

characterised by 

means for utilization of a received group feedback 
report by considering the percentage of the users for 
which said feedback report applies and, 

means for adaptation of the multicast /broadcast 
transmission accordingly to the utilized feedback 
report . 

11. System adapted to perform reporting on 
multicast/broadcast transmission wherein a multicast 
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- . source provides the multicast/broadcast transmission to. . - 
users being registered to nnilticast groups 
characterised in that 

5 said system has multicast source according to claim 9. 

intermediate node according to claim 8 means for 
determination of group structure and means for real time 
determination of distribution characteristics considering 
cell related characteristics determination and the group 

10 structure. 



IS 
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Abstract 



The invention relates to a method, intermediate node, 
multicast so\irce, and system for reporting on 
multicast/broadcast transmission wherein a multicast source 
provides the multicast/broadcast transmission to users being 
registered to multicast groups. The basic idea is to have an 
intermediate node in the wireless network taking care of an 
* aggregated' RTCP reporting, rather than that each user 
individual performs its own reports. The aggregated' RTCP 
reporting or general one feedback report per multicast group 
is generated. A real time determination of distribution 
characteristics is performed considering cell related 
characteristics determination and the group structure and. 
The generation of the feedback report is based on the real 
time determination of distribution characteristics wherein 
said feedback report includes additional information 
including the niimber of users to which said feedback report 
applies. Said feedback report is sent to the multicast 
source, which utilizes the group feedback report by 
considering the percentage of the users for which said 
feedback report applies. The multicast /broadcast transmission 
is adapted accordingly ta the utilized feedback report. 
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